SBN Services Cluster Connection Point

This is an example, not a recommendation. It records a configuration Innovative built and proved end to end in its own lab, and is provided for informational purposes only. Innovative does not support or recommend any particular system. Licensing, networking, security policy, and infrastructure differ between installations — verify every address, name, port, and account against your own environment and standards, and involve your database and network administrators, before running any command or configuration found here.

The Cluster Connection Point gives every client one address for the databases. This page does the same for the SBN Services: the Concentrator dials one virtual IP, and Windows Server Failover Clustering moves that address — and the Front End services behind it — between two Services machines.

The virtual IP is a standard Generic Service cluster role. Everything below is Microsoft's documented procedure.

What you need first

• Two Services machines, A and B, each carrying the same SBN Services build in the same install path, with the same Front End instance numbers.
• The databases already reachable by one name, as in Cluster Connection Point.
• One spare static IP address on the Services machines' subnet, outside any DHCP scope, that nothing else answers on.
• A name for it. This example uses SBN-SERVICES. Alphanumerics, hyphens and underscores only; NetBIOS reads only the first 15 characters.
• A third machine to test from — neither Services machine. A machine can always reach its own address, so testing on A or B proves nothing.
• The Concentrator machine, able to open TCP to the Services subnet.
• Local administrator rights on both Services machines.

This example uses two Front End instances. Instance 1 listens on <FE1_PORT> and <FE1_PORT2>; instance 2 listens on <FE2_PORT> and <FE2_PORT2>.

Step 1 — Reserve the address and the name

Have the address reserved for the Services role's exclusive use. Then confirm, on both Services machines, that the address sits in a live subnet and that nothing already answers on it.

Standalone or workgroup machines with no DNS server: there is nothing to register the name in, so add it to hosts on both Services machines, on the Concentrator machine, and on the test machine. Domain-joined installations skip this — the cluster registers the name itself.

This check is not optional. The cluster brings the IP Address resource online on whichever machine takes the role, so if the address cannot come online there — the subnet missing from that machine, or something else already answering on the address — the whole role fails and falls back to the machine it came from.

Verify

• The address is recorded, static, and outside any DHCP scope.
• Each machine shows an adapter in the virtual IP's subnet.
• Test-Connection returns False on both machines.

Step 2 — Build the cluster on the two Services machines

The Services machines need their own two-node failover cluster, built the same way a database pair's cluster is built in High Availability — determine domain or workgroup, install the Failover Clustering feature and allow the peer machine through the firewall on both, then follow the branch that matches. Use a different cluster name and a different cluster core VIP from any existing cluster's. No shared storage is needed, and the SQL Server steps do not apply here.

Where the Services run on the same two machines as the databases, they are already cluster nodes: skip this step and use the existing cluster in Step 4.

Verify

Both machines Up, and a quorum model with a witness — a two-node cluster without one loses quorum when a machine goes down.

Step 3 — Install the Front Ends identically on both machines

The cluster starts a service on whichever machine holds the role, so both machines carry the same installation: same install path, same instance numbers, same ports, same settings.

In each instance's Properties screen, on both machines, set:

• Listening Port 1 and Listening Port 2 — the same ports on A and on B, and a distinct pair per instance.
• Receive Timeout (in seconds) — 60. The shipped default of 1 closes the Concentrator's host connection after one second of silence, so the line drops and redials continuously and a failover cannot be told apart from a normal idle drop.
• Server — the database cluster name. The Front End reads its database host name from its own settings file and resolves that name through DNS or hosts, so on workgroup machines the name needs a hosts entry on both Services machines.

Settings files are encrypted; write them from the service's Properties screen, never by hand.

Set every Front End service to Manual start on both machines — the cluster starts and stops them, and a service set to Automatic starts on the machine that does not own the role:

Allow the Front End ports inbound on both machines:

Prove each instance runs on each machine, one machine at a time. With every Front End stopped on B, start them on A, read the log, then stop them; repeat with A stopped and B started:

Running the same instance on both machines at once puts two copies of one instance on the same queue in the same database.

Verify

• Each Front End's log shows a successful database connection and Now listening on port <n> on both machines.
• The ports listen on 0.0.0.0 — the Front End binds every address, so it serves the virtual IP with no further configuration.
• Every Front End service reports Manual on both machines, and the firewall rules exist on both.
• Every Front End service is Stopped on both machines before Step 4.

Step 4 — Create the cluster role

One role holds the virtual IP, its network name, and one Generic Service resource per Front End instance. Create the role from the first instance:

Expect a warning. The command reports "There were issues while creating the clustered role" and the report names the other machine under "The nodes that cannot host this role". The scan reads a node-capability view taken before the service was registered everywhere; the role comes online anyway and both machines appear in the resource's owner list. Confirm with the test move in Step 6 rather than acting on the warning.

Add a Generic Service resource for each additional instance, point it at that instance's service, make it depend on the IP address, and bring it online:

Verify

Then read the owner list of each Generic Service resource:

The group Online on one machine; the IP Address, the Network Name and one Generic Service per instance all Online; both machines in each Generic Service resource's owner list. From the third machine, Test-NetConnection -ComputerName SBN-SERVICES -Port <FE1_PORT> returns TcpTestSucceeded : True, and so does the second instance's port. Each Front End service reads Running on the owning machine and Stopped on the other.

Step 5 — Point the Concentrator at it

Each Concentrator host line carries one endpoint — the virtual IP. The cluster moves that address, so a failover list of real Front End addresses is not needed and the line is never reconfigured.

Stop the Concentrator, then set each host line to the virtual IP and that instance's first listening port. In the host line's concport_<n>.txt:

The endpoint syntax is host,port — a comma between the host and the port, and a space between endpoints if more than one is listed. Start the Concentrator again.

Verify

• Both host lines show as connected in the Concentrator's line display.
• log\Error.txt next to the executable shows Connection Successfull for each host line.
• The Front End log on the owning machine shows Connection established by the Concentrator's address for each line.
• A test signal from a receiver reaches SBN.

Step 6 — Test it

Test with signals flowing, not with an idle Concentrator — the point is that alarms keep arriving.

1. Have a receiver send signals continuously into the Concentrator, and note the starting count in the immediate queue table.
2. Move the role to the other machine: Move-ClusterGroup -Name SBN-SERVICES -Node <OTHER_MACHINE>.
3. The Front End services stop on the first machine and come back on the second within 5 to 6 seconds; the Concentrator's host lines drop and re-dial on their own retry cadence, around 20 to 25 seconds. The Concentrator queues signals while the lines are down and drains that queue on reconnect.
4. Re-run the count. It keeps rising, and the Concentrator's own sequence numbers have no gap across the move.
5. Move the role back and repeat. A failover that only works in one direction is not a tested failover.
6. Then end one Front End process on the machine that owns the role. The cluster restarts that service in place within 3 to 7 seconds; the role does not move and the virtual IP does not change. The other Front End instance keeps delivering throughout, and only the host line pointed at the restarted instance re-dials.

Verify

• The role came online on the other machine, and back again, with every resource Online each time.
• Both host lines re-dialled on their own.
• The signal count kept rising and the sequence numbers have no gap across both moves and the process kill.
• Nothing on the Concentrator was reconfigured at any point.

Reference links

1. Failover Clustering overview
2. Add-ClusterGenericServiceRole
3. Add-ClusterResource
4. Add-ClusterResourceDependency
5. Move-ClusterGroup
6. Get-ClusterGroup